The problem of writing error-free computer programs has plagued programmers since the very beginning. Sophisticated schemes for automatically ferreting out program errors and bugs of all kinds, including lexical, syntactic, semantic and logical, have been developed. However, these schemes have generally been directed to enforcing adherence to concrete programming standards inherent in the definition of the programming language itself and not to more extrinsic quality-related concerns, such as language evolution, portability, testing costs and language-specific feature exploitation. Many of these quality-related concerns can be expressed as rules amenable to automated implementation.
The first of these quality-related concerns is caused by the inevitable evolution of programming languages through the extension of features or the introduction of an entirely new language superset. For example, the C++ programming language is by design a superset of the C programming language to make it more accessible to the large number of existing C language programmers. The problem with language evolution is that programmers familiar with the original language often cling to the same old programming practices more out of habit than good sense. Moreover, features formerly preferred have sometimes been refined or replaced by new features in the successor language, yet are largely ignored in favor of the old.
Another concern is portability. Experienced programmers are generally aware of the horizontal portability concerns for different target computing platforms. However, vertical portability concerns relating to the migration of language features to a standardized version of the language, such as an ANSI/ISO standard, are easily overlooked, especially when a compiler fails to implement or acknowledge the proposed standardized features.
A third concern is avoiding unnecessary software testing which is labor intensive and accounts for approximately 50 percent of commercial software development costs. Often, the need to test software is caused by poor or inefficient programming practices. A more disciplined programming style would help diminish testing costs in many cases.
Finally, a concurrent concern to language evolution is a need to fully exploit the language-specific features of the chosen programming language. For instance, two features of the C++ programming language are strong type safety and extensibility, features formerly unavailable in the C language. Even seasoned C language programmers can sometimes overlook these features.
Other quality-related problems are caused by inexperience or lack of exposure to other programmers. As in most disciplines, knowledge of a preferred solution to a commonly encountered problem is generally passed from programmer to programmer in the time-honored oral tradition. This also means that a programmer will only grow insofar as he is able to obtain exposure to other programmers. It is unlikely a lone programmer will quickly adopt a new solution to a solved problem absent some guidance from a sage source.
One system for checking software based on rules is embodied in a computer program called lint++, as described in S. Meyers, Effective C++ 50 Specific Ways to Improve Your Programs and Designs, p. xi (Addison-Wesley 1992), the disclosure of which is incorporated herein by reference. However, this system only focuses on the particular software constructs for the C++ programming language and does not formalize a great majority of the guidelines used by experienced programmers.
Another system for checking software based on rules is embodied in a computer program product called CodeAdvisor, manufactured by Hewlett-Packard Company, Palo Alto, Calif., and described in E. Bailey, C++ SoftBench CodeAdvisor 5.0, SoftBench Insights, pp. 5-6 (Dec. 1995), the disclosure of which is incorporated herein by reference. However, this system also only focuses on the particular software constructs for the C++ programming language and requires rules that are reliant on detailed source code information stored in a static database.
Therefore, what is needed is a system and method for automatically checking source code quality based on rules of programming style and technique. Such a system and method would operate beyond the boundaries of the raw programming language definition and impart expert programming language knowledge by applying rules embodying extrinsic quality-related concerns, such as language evolution, portability, testing costs and language-specific feature exploitation. Preferably, such a system and method would incorporate error message outputting and global and specific rule suppression features.